Tbh, this feels quite like the hammer.

Could you test an approach like this inside the chain-at-start block of process_ucontext()

sigset_t mask, old_mask;
sigemptyset(&mask);
sigaddset(&mask, uctx->signum);
sigprocmask(SIG_BLOCK, &mask, &old_mask);

invoke_signal_handler(uctx->signum, uctx->siginfo, (void *)uctx->user_context);

if (ip != get_instruction_pointer(uctx)
    || sp != get_stack_pointer(uctx)) {
    // No need to restore the signal mask here: sigreturn will 
    // restore it from the saved ucontext.
    return;
}

// once we know we own the signal, unmask again
sigprocmask(SIG_SETMASK, &old_mask, NULL);

Thanks for the suggestion. I tested it on an emulator and faced a couple of issues:

1. sigprocmask seems to be intercepted by libsigchain on Android. A raw syscall(SYS_rt_sigprocmask, SIG_BLOCK, ...) works, though.

2. unmasking delivers a pending SIGSEGV and kills the process

   Mono restores SIG_DFL and re-raises SIGSEGV:

   sigaction(SIGSEGV, &saved_default_handler, NULL);
   raise(SIGSEGV);

   With the signal blocked, the raise() creates a pending signal instead of being delivered immediately. When unmasked, the pending SIGSEGV is delivered, but the handler is now SIG_DFL, so it terminates the process before sentry-native can capture the crash.

   I guess leaving it unmasked would have more or less the same trade-off as the original SA_NODEFER removal approach, basically losing recursive crash detection. What if we would restore our handler, and consume the the pending signal with sigtimedwait?

1. sigprocmask seems to be intercepted by libsigchain on Android. A raw syscall(SYS_rt_sigprocmask, SIG_BLOCK, ...) works, though.

What is the observed effect? If libsigchain is the callee of a sigprocmask() call and it happens from inside the signal handler, then it normally passes it on to the linked sigprocmask(), so yes... this will go through libsigchain, but what effect do you see?!

// restore our handler
struct sigaction current;
sigaction(uctx->signum, NULL, &current);
if (current.sa_handler == SIG_DFL) {
    sigaction(uctx->signum, &g_sigaction, NULL);
}

// consume pending signal
struct timespec timeout = { 0, 0 };
sigtimedwait(&mask, NULL, &timeout);

// unmask
syscall(SYS_rt_sigprocmask, SIG_SETMASK, &old_mask, NULL,
    sizeof(sigset_t));

Do we need to restore our handler? It should be enough to just sigwait()/sigtimedwait() (which are both not async-signal-safe), since they both just block the calling thread until the pending signal arrives (which in our case is already there). Or do you mean for the case of reentering?

What is the observed effect? If libsigchain is the callee of a sigprocmask() call and it happens from inside the signal handler, then it normally passes it on to the linked sigprocmask(), so yes... this will go through libsigchain, but what effect do you see?!

The intercepted sigprocmask call returns 0 indicating success, but the signal isn't blocked. Works fine with a raw syscall.

Do we need to restore our handler? It should be enough to just sigwait()/sigtimedwait() (which are both not async-signal-safe), since they both just block the calling thread until the pending signal arrives (which in our case is already there). Or do you mean for the case of reentering?

Yes, it's for trying to preserve the recursive crash detection with SA_NODEFER.

The intercepted sigprocmask call returns 0 indicating success, but the signal isn't blocked. Works fine with a raw syscall.

Could be this: https://cs.android.com/android/platform/superproject/main/+/main:art/sigchainlib/sigchain.cc;l=653-661

Yes, but we shouldn't even be reaching that point, because right before that, libsigchain checks whether we are in the signal handler (via TLS), and directly calls the "linked" sigprocmask.

The check for claimed signals is only relevant outside of signal handlers, because it could prevent special handlers installed by libsigchain from being blocked.

But sigprocmask from within the handler would only defer delivery until the current signal handler leaves. At the point where any of our signal handlers or the .NET signal handler is invoked, all special handlers have already been invoked.

Bug: The function returns early if the chained handler modifies ip or sp, but it does so without unmasking the signal or consuming the pending signal raised by the handler.
_{Severity: HIGH}

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: src/backends/sentry_backend_inproc.c#L1598-L1599

Potential issue: In the signal handler, a signal is masked before invoking a chained
handler. If this chained handler re-raises the signal (e.g., via `raise(signum)`) and
also modifies the instruction pointer (`ip`) or stack pointer (`sp`), the function will
`return` early. This early return path skips the logic that consumes the now-pending
signal with `sigtimedwait` and unmasks it with `sigprocmask`. This leaves the process
with a pending signal that is still masked, preventing its delivery and potentially
causing undefined behavior or crashes later on.

Raw syscall buffer overflow on 32-bit Android

High Severity

On 32-bit Android (LP32), bionic's sigset_t is only 4 bytes, but _NSIG / 8 evaluates to 8. The raw syscall(SYS_rt_sigprocmask, SIG_BLOCK, &mask, &old_mask, _NSIG / 8) tells the kernel to write 8 bytes into the 4-byte old_mask buffer, causing a stack buffer overflow. The project explicitly targets armeabi-v7a and x86 (32-bit ABIs). Bionic's libc wrapper normally handles this size mismatch via an internal kernel_sigset_t union, but the raw syscall bypasses that conversion.